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Field of the Invention 

The present invention relates to a bearer note, for example, a traveler's 
check that is generated at a remote location using local equipment, and systems 
and methods for generating and clearing such notes. 

Background of the Invention 

Traveler's checks are well-known payment means offering advantages, 
such as security and wide acceptance. However, traveler's checks have a 
disadvantage in that a purchaser must physically go to an office of a traveler's 
check seller, such as a bank or travel service, in order to purchase and receive the 
checks. There are a limited number of such offices and their hours of operation 
are limited. This is inconvenient for the purchaser, who must travel to a seller's 
office during the specified hours. Some have attempted to deal with this problem 
by allowing purchasers to order checks over the telephone, but the checks must 
be delivered by mail or express service, causing a significant delivery delay. 
Others have attempted to deal with the problem by providing machines similar to 
automated teller machines (ATM), which issue traveler's checks. However, the 
purchaser still must find and travel to such a machine. In addition, such machines 
dispense only a limited selection of check denominations. As such, there is a need 
for a system with which purchasers may obtain traveler's checks at any time, in 
any denominations and without having to travel. 



Summary of the Invention 

The present invention is a system and method for issuing traveler's checks 
at a user's home or business using the purchaser's own computer system. This 
5 allows the user to obtain traveler's checks at any time, in any denominations and 
without having to travel to an issuer location. 

User information, including a user identifier and a quantity and face value 
of bearer notes to be issued, are received from a user at an issuer central 
controller. The issuer central controller generates at least one code for generating 
JO the bearer notes and transmits the code to the user. Bearer notes including the 
% code are then generated. 

j= Preferably, the user has registered with the note issuer prior to issuance of 

Zl the notes. During registration, information relating to the user, such as identifying 

m 
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information and an account identifier are received from the user and stored in a 
Ll5 database. A user identifier is transmitted to the user. 

03 

£ Brief Description of the Drawings 

The details of the present invention, both as to its structure and operation, 
can best be understood by referring to the accompanying drawings, in which like 
20 reference numbers and designations refer to like elements. 

Fig. la is a block diagram illustrating the issuance, acceptance and 
clearance of a user-generated traveler's check, according to the present 
invention. 

Fig. lb shows a user-generated traveler's check, according to the present 
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invention. 

Fig. 2a is a block diagram of a system for issuing and clearing a 
user-generated traveler's check, according to the present invention. 

Fig. 2b is an exemplary block diagram of an issuer central controller system 
200 of Fig. 2a. 

Fig. 2c is an exemplary block diagram of a remote user terminal 252 or 
merchant terminal 254 of Fig 2a. 

Fig. 3a is an exemplary format of a traveler's check order database 225 of 
Fig. 2b. 

Fig. 3b is an exemplary format of a traveler's check database 222 of Fig. 

2b. 

Fig. 3c is an exemplary format of an issuer software membership database 
of Fig. 2b. 

Fig. 3d is an exemplary format of a merchant registration database 223 of 
Fig. 2b. 

Figs. 4a and 4b are flow diagrams of a user-generated traveler's check 
creation process 400, which is implemented in the system of Fig. 2a. 

Figs. 5a and 5b are more detailed flow diagrams of a user-generated 
traveler's check creation process 500, which is a portion of process 400 of Figs. 
4a-b that is implemented in remote user terminal 252 of Fig. 2a 

Figs. 6a and 6b are more detailed flow diagrams of a user-generated 
traveler's check creation process 600, which is a portion of process 400 of Figs. 
4a-b that is implemented in issuer central controller 200 and issuer voice response 
unit (IVRU) of Fig. 2a. 



Figs. 7a and 7b are flow diagrams of a user-generated traveler's check 
cancellation process 700, which is implemented in issuer central controller 200 
and issuer voice response unit (IVRU) of Fig. 2a. 

Figs. 8a and 8b are flow diagrams of a user-generated traveler's check 
clearing process 800, which is implemented in issuer central controller 200 and 
issuer voice response unit (IVRU) 230 of Fig. 2a. 

Fig. 9 is a flow diagram of an issuer voice response verification process 
900, which is performed as part of step 806, shown in Fig. 8a, and is implemented 
in issuer central controller 200 and issuer voice response unit (IVRU) 230 of Fig. 
2a. 

Detailed Description of the Invention 

The data and material flow of the issuance, acceptance and clearance of a 
user-generated bearer note, according to the present invention, is shown in Fig. 
la. In the described embodiment, the bearer note comprises a traveler's check, 
which is a well-known payment draft issued by a bank or express company, 
signed by the purchaser at the time of purchase and again at the time of cashing 
as a security precaution. Well-known traveler's check issuers include American 
Express, Citibank, Thomas Cook, etc. 

Traveler's check issuer 102 provides software 109 and, optionally, 
traveler's check stock paper 110 to user 104. User 104 installs software 109 on 
an appropriate computer system and registers appropriate information 112 in a 
user database maintained by issuer 102. The user may register by sending in a 
registration mailer that accompanies the software. The mailer may include 



preprinted information identifying the particular copy of software that the user 
has, such as a serial number of the software. The user enters identifying 
information on the , mailer, such as his name and address, etc. The user may also 
be required to enter a credit card account number that will be used to pay for any 
traveler's checks that are issued, as well as a password to be used during the 
issuance process. Registration may also be performed over the telephone, with 
either a human operator or an automated voice response unit, which will prompt 
the user for the required information, or using the remote user terminal and a 
modem or network connection to communicate the required information to a 
central controller maintained by issuer 102. 

When user 104 wishes to obtain a traveler's check, user 104 generates the 
check using his local equipment in a process described below. User 104 may 
retain the check for spending up until a pre-established expiration date, at which 
time the check will be non-negotiable. User 104 may use the check at merchant 
106 by countersigning and transferring it to merchant 106. Merchant 106 may be 
a seller of goods or services, or may be a bank or money exchange bureau. 
Before accepting the check, merchant 106 transmits a verification message 114 to 
issuer 102. Issuer 102 verifies the validity of the check, and if it is valid, transmits 
aerification code) 116 to merchant 106. Upon receipt of the Verification code^ 
merchant 106 accepts the check from user 104. 

Merchant 106 deposits 124 the countersigned check at its merchant bank 
108. Merchant bank 108 forwards the check 118 to issuer 102 for clearing and 
payment. Upon clearing the check, issuer 102 transmits payment 120 to merchant 
bank 108, which is credited to the account of merchant 106. 



A user-generated traveler's check 118 according to the present invention 
is shown in Fig. lb. Check 118 includes a signature 118-1 of the user, a 
denomination 118-2 and face value 118-3, an optional counter-signature 118-6, 
and a serial number 118-4. Counter-signature 118-6 is optionally inscribed by the 
user upon purchase, and signature 118-1 is inscribed by the user upon use. As 
will become apparent from a consideration of the following description, while 
counter-signature 118-6 provides some increased level of security, the invention 
may be practiced without the countersignature. 

A denomination 118-2, face value 118-3 and serial number 118-4 are 
printed on the check by the user during the issuance process, which is described 
below. Serial number 118-4 is generated based on information related to the 
check and the user, such as, for example, the face value of the check and the 
name of the user, and is printed on the check. The serial number is used by 
merchant 106 to verify a check before accepting it. 

A system for issuing and clearing a user-generated traveler's check, 
according to the present invention, is shown in Fig. 2a. The system includes 
issuer central controller 200, which is a communication and database system 
maintained by traveler's check issuer 102 of Fig. la, issuer voice response unit 
230, communication network 250, a plurality of remote user terminals 252a-z, and 
a plurality of merchant terminals 254a-z. Communication network 250 provides 
communications among the other elements of the system. Issuer central controller 
200 communicates information with remote user terminals 252 and verification 
information with merchant terminals 254 and stores the information for later use. 

In one embodiment, a remote user terminal 252 communicates registration 



and issuance information directly with issuer central controller 200. In this 
embodiment, network 250 provides data communications between issuer central 
controller 200 and remote user terminal 252. In one alternative of this 
embodiment, network 250 is the public switched telephone network, while in 
other alternatives, network 250 may be the Internet (with appropriate security 
measures) or a private wide-area network. 

In another embodiment, remote user terminal 252 is not in direct 
communication with issuer central controller 200. In this embodiment, a user 
operating the remote user terminal places a call to issuer central controller 200. 
The call is handled by a two-way audio connection over communication network 
250, which is the public switched telephone network. The call is routed to and 
handled by issuer voice response unit (IVRU) 230. The user receives voice 
prompts and tones from IVRU 230 and transmits commands using touch-tone 
signals or voice commands. Registration and issuance information is entered and 
received by the user via IVRU 230. The information received by the user is then 
entered by the user into remote user terminal 252. 

Merchant terminal 254 communicates with issuer central controller in a 
manner similar to remote user terminal 252. In one embodiment, a merchant 
terminal 254 communicates verification information directly with issuer central 
controller 200. In this embodiment, network 250 provides data communications 
between issuer central controller 200 and merchant terminal 254. In one 
alternative of this embodiment, network 250 is the public switched telephone 
network, while in other alternatives, network 250 may be the Internet (with 
appropriate security measures) or a private wide-area network. 



In another embodiment, merchant terminal 254 is not in direct 
communication with issuer central controller 200. In this embodiment, a merchant 
operating a merchant terminal places a call to issuer central controller 200. The 
call is handled by a two-way audio connection over communication network 
250, which is the public switched telephone network. The call is routed to and 
handled by issuer voice response unit (IVRU) 230. The merchant receives voice 
prompts and tones from IVRU 230 and transmits commands using touch-tone 
signals or voice commands. Verification information is entered and received by 
the user via IVRU 230. The information received by the merchant is then entered 
by the user into merchant terminal 254. 

An exemplary issuer central controller system 200 is shown in Fig. 2b. 
Controller 200 includes central processing unit (CPU) 202, which is connected to 
random access memory (RAM) 204, read-only memory (ROM) 206, 
communication port 210, cryptographic processor 212 and data storage device 
220. CPU 202 may comprise a microprocessor, for example, an INTEL PENTIUM 
processor, or CPU 202 may comprise a mini-computer or mainframe processor. 
RAM 204 and ROM 206 store program instructions that are executed by CPU 
202 and data that is used during program execution. Communication port 210 
couples controller 200 to issuer voice response unit 230, network adapter 209 
and modem 216, which provide communications between issuer central controller 
200 and the remote user terminals 252 and/or merchant terminal 254. A typical 
system need not include all three devices, voice response unit 230, network 
adapter 209 and modem 216. Only those devices that are needed to implement 
the communication techniques selected by the check issuer must be present. 



Preferably, communications over the public switched telephone network, via 
modem 216, will be used. 

Cryptographic processor 212 encrypts and decrypts digital information 
which is used to ensure security of the traveler's checks. In one embodiment, 
processor 212 is a separate physical processor, such as a networked computer 
system or a daughtercard processor, running cryptographic software. In another 
embodiment, processor 212 is implemented in software that is executed by CPU 
202. Data storage device 220, which stores data that is used by the present 
invention, may comprise, for example, a magnetic disk and/or optical disk and may 
also comprise a magnetic tape. 

Storage device 220 includes transaction processor 221, traveler's check 
database 222, merchant registration database 223, issuer software membership 
database 224 and traveler's check database 225. Transaction processor 221 
accepts input from CPU 202, accesses the appropriate database and stores 
information in or retrieves information from that database. Transaction processor 
221 may comprise a separate processor or may comprise a part of CPU 202. 
Traveler's check database 222 stores information about each traveler's check 
that is issued. Merchant registration database 223 stores information about each 
merchant that accepts traveler's checks. Issuer software membership database 
224 stores information about each software user who has registered with the 
issuer. Traveler's check order database 225 stores information about each 
traveler's check order that has been placed. 

An exemplary remote user terminal 252 is shown in Fig. 2c. Terminal 252 
includes computer system 260, which is connected to printer 274, modem 275, 



network adapter 276 and security device 277. Computer system 260 includes 
central processing unit (CPU) 261, which is connected to random access memory 
(RAM) 262, read-only memory (ROM) 263, communication port 264, 
cryptographic processor 270 and data storage device 271. RAM 262 and ROM 
264 store program instructions that are executed by CPU 260 and data that is 
used during program execution. CPU 261 is coupled to printer 274, which is a 
conventional printer, such as a dot-matrix, ink jet or laser printer. 
Communications port 264 couples computer 260 to modem 275 and network 
adapter 276, which provide communications between the remote user terminal 
252 and issuer central controller 200, over communications network 250. A 
typical system need not include both devices, network adapter 276 and modem 
275. Only the device that is needed to implement the communication techniques 
selected by the check issuer must be present. In one embodiment, the terminal is 
coupled by modem 275 to the public switched telephone network. In another 
embodiment, the terminal is coupled to a private wide-area network via network 
adapter 276. Preferably, communications over the public switched telephone 
network, via modem 275, will be used. 

Cryptographic processor 270 encrypts and decrypts digital information 
which is used to ensure security of the traveler's checks. In one embodiment, 
cryptographic processor 270 is a separate physical processor running 
cryptographic software, such as a daughtercard processor or a processor 
contained in a "dongle" connected to computer system 260. In another 
embodiment, cryptographic processor 270 is implemented in software that is 
executed by CPU 261. In another embodiment, cryptographic processor 270, 
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which is either hardware or software, communicates with security device 277, 
which is connected to computer system 260, typically in the form of a "dongle". 
Security device 277 may contain the cryptographic keys that are used to encrypt 
and decrypt data. 

Data storage device 271, which stores data that is used by the present 
invention, may comprise, for example, a magnetic disk and/or optical disk and may 
also comprise a magnetic tape. Data storage device 271 includes transaction 
processor 272 and traveler's check database 273. Transaction processor 272 
accepts input from CPU 261, accesses the appropriate database and stores 
information in or retrieves information from that database. Transaction processor 
272 may comprise a separate processor or may comprise a part of CPU 261. 
Traveler's check database 272 stores information about each traveler's check 
that is issued by a remote user terminal 252 or each check that is accepted at a 
merchant terminal 254. 

Printer 274 prints the traveler's checks to be issued in response to 
commands from computer system 260. Any modern printer capable of color 
printing may be used. Paper stock is inserted into printer 274, which then prints 
indicia such as the denomination 118-2, face value 118-3 and serial number 1 18-4, 
shown in Fig. lb, according to a process described below. Conventional paper 
stock may be used for printing the checks. Optionally, special traveler's check 
paper stock, which may include, for example: preprinted information such as the 
issuer's name, or security features that prevent duplication (i.e. glyphs, 
watermarks, holograms, etc.), may be used. 

Merchant terminal 254 is used only for verifying individual traveler's 
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checks at the time of acceptance. Although a computer system similar to that of 
remote user terminal 252 may be used, this is not necessary. A device similar to 
the well-known credit card authorization terminals that are in widespread use 
may be used. Alternatively, the checks may be verified over the telephone. 

An exemplary format of a traveler's check order database 225 is shown in 
Fig. 3a. Database 225 includes a plurality of records, such as, for example, record 
314a. Each record corresponds to one order of traveler's checks and includes an 
order number field 302, a number of checks field 304, a total purchase amount 
field 306, a registration code field 308, a verification code field 310 and a 
completion code field 312. A record 314 is established for each traveler's check 
order that is received by central controller 200. An identification code that 
uniquely identifies each received order is generated by central controller 200 and 
stored in order number field 302. The number of checks issued in the order is 
stored in number of checks field 304. The total monetary value of the traveler's 
checks purchased in the order is stored in total purchase amount field 306. A 
code that was received from the user at the initiation of the check issuance 
process, the registration code, is stored in registration code field 308. A code that 
indicates that the information entered by the user during the check creation 
process has been verified by the traveler's check issuer, is stored in verification 
code field 310. The verification code is also transmitted to the user. A code that 
indicates that the remote user terminal has completed the check creation process 
is stored in completion code field 312. The completion code is received from the 
user. 

An exemplary format of a traveler's check database 222 is shown in Fig. 
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3b. Database 222 includes a plurality of records, such as, for example, record 330. 
Each record corresponds to one traveler's check that was issued and includes a 
date field 320, an order number field 321, a check serial number field 322, a check 
amount field 323, a registration code field 324, an authorization code field 325, a 
status field 326, a date used field 327 and a merchant location field 328. A record 
330 is established for each traveler's check that is issued. The date on which a 
check was issued is stored in date field 320. The order number that identifies the 
order in which the check is included is stored in order number field 321. 
Information relating to the order is stored in a record in traveler's check order 
database 225 of Fig. 3a. The number stored in field 321 is the same as the number 
stored in field 302 of that record. The serial number of the check, which uniquely 
identifies the check, is stored in serial number field 322. The monetary face value 
amount of the check, including an indicator of the currency, is stored in check 
amount field 323. The registration code is stored in field 324. The code that is 
sent to the merchant that accepts the check, which authorizes the merchant to 
accept the check, is stored in authorization code field 325. The status of the 
check is stored in status field 326. When the check is issued, the status is set to 
"Uncashed". Later, after the user has used the check and the authorization code 
has been sent to the accepting merchant, the status is set to "Cashed". The date 
on which the check is cashed is stored in date used field 327. An identification 
code that uniquely identifies the particular business location of the merchant that 
accepted the check from the user is stored in merchant location field 328. 

An exemplary format of an issuer software membership database 224 is 
shown in Fig. 3c. Database 224 includes a plurality of records, such as, for 
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example, record 348a. Each record corresponds to one traveler's check software 
package that is registered for use, and includes a name field 340, an address field 
341, a telephone number field 342, a credit card account number field 343, a 
credit card expiration field 344, an order number field 325 and a customer ID 
number field 346. A record 348 is established for each user who registers with 
the traveler's check issuer. The user name is stored in name field 340. The user 
address is stored in user address field 341. The user telephone number is stored in 
telephone number field 342. The account number of the credit card that is used 
to purchase traveler's checks is stored in credit card account number field 343. 
The expiration date of the credit card is stored in credit card expiration field 344. 
An order number that identifies each order of traveler's checks that the user has 
placed is stored in order number field 345. An identification number that 
uniquely identifies the user is stored in customer ID field 346. 

An exemplary format of a merchant registration database 223 is shown in 
Fig. 3d. Database 223 includes a plurality of records, such as, for example, record 
366a. Each record corresponds to a merchant that is authorized to accept 
traveler's checks, or to a particular business site of a merchant, if the merchant has 
more than one business site. Each record includes a name field 360, a store name 
field 361, a telephone number field 362, a location field 363 and a registration ID 
number field 364. A record 348 is established for each merchant or merchant site 
that registers with the traveler's check issuer. The merchant name is stored in 
name field 360. The name of the merchant site is stored in store name field 361. 
The telephone number of the merchant or the merchant site is stored in telephone 
number field 362. The geographic location of the merchant site is stored in 
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location field 363. An identification number that uniquely identifies the merchant 
or merchant site is stored in registration ID field 364. 

A user-generated traveler's check creation process 400, which is 
implemented in the system of Fig. 2a, and uses the databases shown in Figs. 3a-d, 
is shown in Figs. 4a : b. Steps 402-418 of process 400 are shown in Fig. 4a. 
Process 400 begins with step 402, in which a user enters information, which 
includes the total monetary amount of traveler's checks desired, the 
denominations and number of checks of each entered denomination that are 
desired, and the date, into a remote user terminal. Preferably, special check 
creation software is executing on the remote user terminal and the information is 
entered into the check creation software. In addition, the check creation 
software may automatically generate some of the required information. For 
example, the software may automatically enter the date, and may automatically 
generate the total monetary amount from the denominations and number of each 
denomination desired. In step 404, a check registration code is generated based 
on the entered information, for example as a function of the check denominations, 
date of the code generation, and total amount of the checks. This registration 
code is then displayed to the user on the remote user terminal. In step 406, the 
user places a telephone call to the issuer voice response unit (IVRU) 230 of 
central controller 200, and enters the customer ID and the check registration code 
in response to audio and voice prompts generated by the IVRU. In step 408, the 
IVRU transmits the customer ID and the check registration code to the central 
controller. In step 410, the central control determines whether the received 
customer ID is found in membership database 224, shown in Fig. 2b. If the 
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received customer ID is not found in membership database 224, then in step 412, 
the IVRU informs the user of this fact and tells the user to register his copy of the 
software. In a preferred embodiment, the IVRU would then perform the 
registration process with the user. 

If the received customer ID is found in membership database 224, then in 
step 414, the IVRU transmits the check denominations and numbers of each 
denomination, which were contained in the registration code, to the user for 
verification. In step 416, the user verifies the check denominations and numbers 
of each denomination and indicates to the IVRU whether or not the information is 
correct. If the information is not correct, then in step 418, the IVRU prompts the 
user to re-enter the information into the remote user terminal, and the process 
loops back to step 402. If the information is correct, the process continues with 
step 420. 

Steps 420-426 of process 400 are shown in Fig. 4b. In step 420, the IVRU 
transmits a verification code to the user. In step 422, the user enters the 
verification code into the remote user terminal. In step 424, the remote user 
terminal generates a completion code based on the verification code, displays the 
completion code to the user and commands the printer to print the traveler's 
checks. In step 426, the user transmits the completion code to the IVRU. In step 
428, the IVRU transmits a transaction complete message to the user. 

In an alternate embodiment of the invention, the actual printing of the 
traveler's checks is deferred until a later date selected by the user. Once all of the 
necessary information is available to create valid checks, they may actually be 
printed at any convenient time. 
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Other embodiments of the check creation process are possible. For 
example, instead of the user placing a telephone call to the IVRU, the remote user 
terminal may establish communications with the central controller over the public 
switched telephone network using a modem, or over a private network using a 
network adapter. The steps of process 400, in which the remote user terminal 
displays information to the user, the user transmits information to the IVRU, the 
IVRU transmits information to the user, and the user enters the information from 
the IVRU into the remote user terminal would be replaced by steps in which the 
remote user terminal transmits information over the communication network to 
the central controller, and the central controller transmits information over the 
communication network to the remote user terminal. 

*3jJ(^ i^iore detailed description of portions of Figs. 4a-b is shown in Figs. 5a-b. 
A user-genehrted traveler's check creation process 500, is shown in Figs 5a-b. 
Process 500 is portion of process 400 of Figs. 4a-b that is implemented in 
remote user terminal 252 of Fig. 2a. Steps 502-510 of process 500 are shown in 
Fig. 5a. Process 500 begir^with step 502, in which the remote user terminal 
receives the traveler's check initiation entered by the user in step 402 of Fig. 
4a. The information includes the toted monetary amount of traveler's checks 
desired, the denominations and number ofS^hecks of each entered denomination 
that are desired, and the date. Preferably, the ren^e user terminal generates some 
of this information, as described above. In step 506?^e cryptographic processor 
generates a check registration code by combining and\ncrypting the .user- 
entered data. In step 508, the remote user terminal displays the\heck registration 
code. As described above, the user transmits the check registration code to the 
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jgninr voic e^response unit (IVRU) and receives a verification code from the IVRU. 
In step 510, the user enters the venlicalion code UiiUUgh-&e4VRU. 

Steps 512-520 of process 500 are shown in Fig. 5b. In step 512, the 
cryptographic processor in the remote terminal decrypts the verification code 
generated by the issuer central controller and entered into the remote terminal by 
the user. In step 514, the decrypted data from the verification code is stored in 
the traveler's check database in the remote user terminal. In step 516, the 
cryptographic processor creates a completion code, which is displayed to the user 
in step 518. In step 520, check data is transmitted to the printer and the traveler's 
checks are printed. 

As described above, other embodiments of the check creation process are 
possible. For example, instead of the user placing a telephone call to the IVRU, 
the remote user terminal may establish communication with the central controller 
over the public switched telephone network using a modem, or over a private 
network using a network adapter. The steps of process 500, in which the remote 
user terminal displays information to the user and the user enters the information 
from the IVRU into the remote user terminal would be replaced by steps in which 
the remote user terminal transmits information over the communication network 
to the central controller, and the central controller transmits information over the 
communication network to the remote user terminal. 

A more detailed description of portions of Figs. 4a-b is shown in Figs. 6a-b. 
A user-generated traveler's check creation process 600, is shown in Figs 6a-b. 
Process 600 is a portion of process 400 of Figs. 4a-b that is implemented in issuer 
central controller 200 and issuer voice response unit (IVRU) of Fig. 2a. Steps 

-18- 



602-616 of process 600 are shown in Fig. 6a. Process 600 begins with step 602, 
in which the IVRU, which received the customer ID and the check registration 
code from the user, sends the received information to the issuer central controller 
for verification. In step 604, the central controller determines whether the 
received customer ID is found in membership database 224, shown in Fig. 2b. If 
the received customer ID is not found in the membership database, then in step 
606, the central controller transmits a "not registered" message to the IVRU, 
which then informs the user by playing the appropriate prompts. If the customer 
ID is found in the membership database, then in step 608, cryptographic 
processor 212 of the central controller, shown in Fig. 2b, decrypts the received 
check registration code. In step 610, transaction processor 221, shown in Fig. 2b, 
interprets the decrypted information from the check registration code. In step 
612, the appropriate portions of the interpreted information are stored in 
traveler's check database 222 of Fig. 2b. In step 614, the appropriate portions of 
the interpreted information are stored in traveler's check order database 225 of 
Fig. 2b. In step 616, the central controller searches membership database 224 for 
the received customer ID. 

Steps 618-626 of process 600 are shown in Fig. 6b. In step 618, the 
cryptographic processor generates a verification code. In step 620, the 
verification code is transmitted to the IVRU, which transmits it to the user. As 
described above, the user enters the verification code into the remote user 
terminal and receives a completion code to transmit to the IVRU. In step 622, the 
central controller receives the completion code from the IVRU. In step 624, the 
completion code is decrypted by cryptographic processor 212 and, in step 626, 
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the decrypted completion code is stored in order database 225. 

As described above, other embodiments of the check creation process are 
possible. For example, instead of the user placing a telephone call to the IVRU, 
the remote user terminal may establish communications with the central controller 
over the public switched telephone network using a modem, or over a private 
network using a network adapter. The steps of process 600, in which the IVRU 
receives information from the user and the IVRU transmits information to the user, 
would be replaced by steps in which the remote user terminal transmits 
information over the communication network to the central controller, and the 
central controller transmits information over the communication network to the 
remote user terminal. 

A user-generated traveler's check cancellation process 700, which is 
implemented in issuer central controller 200 and issuer voice response unit 
(IVRU) of Fig. 2a, is shown in Figs 7a-b. Steps 702-714 of process 700 are 
shown in Fig. 7a. Process 700 begins with step 702, in which the user places a 
telephone call to the IVRU in order to enter a traveler's check cancellation 
request. In step 704, in response to a prompt from the IVRU, the user transmits his 
customer ID to the IVRU. In step 706, in response to a prompt from the IVRU, the 
user indicates to the IVRU whether the cancellation request is for an entire check 
order or for fewer than all the checks in an order. If the cancellation request is for 
an entire order, then the process continues with step 716 of Fig. 7b, in which the 
central controller updates the databases to reflect the cancellation of the 
traveler's checks involved, and credits the user's credit card account with the 
appropriate monetary amount. If the cancellation request is for fewer than all the 
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checks in an order, then in step 708, in response to a prompt from the IVRU, the 
user enters the serial numbers of the checks that are to be canceled. In step 710, 
in response to a prompt from the IVRU, the user indicates whether the checks 
being canceled were lost, stolen, or printed incorrectly. If the checks were lost or 
stolen, then in step 712, the IVRU connects the user to a customer service 
representative, who obtains information regarding the theft or loss. The process 
then continues with step 716 of Fig. 7b, in which the central controller updates 
the databases to reflect the cancellation of the traveler's checks involved, and 
credits the user's credit card account with the appropriate monetary amount. If 
the checks were printed incorrectly, then in step 714, the IVRU transmits 
cancellation information to the central controller for processing. 

Steps 716-718 of process 700 are shown in Fig. 7b. In step 716, the 
central controller updates the databases to reflect the cancellation of the 
traveler's checks involved, and credits the user's credit card account with the 
appropriate monetary amount. In step 718, the IVRU provides the user with a 
cancellation code. 

As described above, other embodiments of the check creation process are 
possible. For example, instead of the user placing a telephone call to the IVRU, 
the remote user terminal may establish communications with the central controller 
over the public switched telephone network using a modem, or over a private 
network using a network adapter. The steps of process 700, in which the IVRU 
receives information from the user and the IVRU transmits information to the user, 
would be replaced by steps in which the remote user terminal transmits 
information over the communication network to the central controller, and the 
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central controller transmits information over the communication network to the 
remote user terminal. 

9^1^ A S 'h^^generated traveler's check clearing process 800, which is 
implemented inS^uer central controller 200 and issuer voice response unit 
(IVRU) 230 of Fig. 2^Xshown in Figs 8a-b. Steps 802-812 of process 800 are 
shown in Fig. 8a. Process 8u8k<begins with step 802, in which a user presents a 
traveler's check to a merchant. In sfe^ 804, the merchant calls the IVRU and, in 
response to prompts from the IVRU, enters theface value and serial number of the 
check. In step 806, the IVRU performs the IVRbsverification process shown in 
Fig. 9, and transmits a verification code to the .merchant. In step 808, upon 
receiving the verification code, the merchant provides cash oSmerchandise to the 
user. In step 810, the merchant writes or prints the verification cocoon the check 
and deposits it in the merchant's bank. In step 812, the merchant banK^ends the 
chrrk to thn \m\cr rl raring hous e. 

Steps 814-824 of process 800 are shown in Fig. 8b. In step 814, upon 
receiving the check from the merchant bank, the issuer finds the record 
corresponding to the serial number of the received check in traveler's check 
database 222 of Fig. 2b. In step 816, the issuer changes the data in check status 
field 326, shown in Fig. 3b, of the found record to indicate that the check has 
been "Cashed". In step 820, the issuer sends the check back to the user, for the 
user's records. In step 822, the issuer clears the face value amount of the check, 
which is credited to the merchant bank. In step 824, the merchant receives the 
funds from the merchant bank. 

As described above, other embodiments of the check clearance process 
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are possible. For example, instead of the merchant placing a telephone call to the 
IVRU, the merchant terminal may establish communications with the central 
controller over the public switched telephone network using a modem, or over a 
private network using a network adapter. The steps of process 800, in which the 
IVRU receives information from the merchant and the IVRU transmits information 
to the merchant, would be replaced by steps in which the merchant terminal 
transmits information over the communication network to the central controller, 
and the central controller transmits information over the communication network 
to the merchant terminal. 

(yft^ Ahs^ssuer voice response verification process 900, which is performed as 
part of step 805>§Jiown in Fig. 8a, and is implemented in issuer central controller 
200 and issuer voice^fc^ponse unit (IVRU) 230 of Fig. 2a, is shown in Fig. 9. 
Process 900 begins with ste^Q02, in which the IVRU receives information from a 
merchant that has received a traveler's check from a user. The received 
information includes the merchant ID, tTh^check serial number and the face value 
amount of the check. In step 904, the IVRU tr&^smits the received information to 
the issuer central controller, for processing. In st^906, the central controller 
determines whether the check serial number and faceValue amount match 
information in traveler's check database 222 of Fig. 2b. If thereS^no match, then 
in step 908, the IVRU tells the merchant to immediately confiscate tffe^heck and 
the clearing process is not completed for that check. 

OS l^-tht^4s-ajaatch, then in step 910, the central controller generate^ 



verification cod^and transmits it to 



The central controller also updates 
information relating to the check in the traveler's chec^^atat>ase. In step 912, 
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ri*PHW44- tem^ verification code to the merc hant. 

As described above, other embodiments of the check creation process are 
possible. For example, instead of the merchant placing a telephone call to the 
IVRU, the merchant terminal may establish communications with the central 
controller over the public switched telephone network using a modem, or over a 
private network using a network adapter. The steps of process 900, in which the 
IVRU receives information from the merchant and the IVRU transmits information 
to the merchant, would be replaced by steps in which the merchant terminal 
transmits information over the communication network to the central controller, 
and the central controller transmits information over the communication network 
to the merchant terminal. 

As described above, the present invention is equally applicable to forms of 
bearer notes other than traveler's checks. For example, the present invention 
may be applied to the generation of certified checks. A certified check is a check, 
such as a personal check or a business check, of a depositor, drawn on a bank, on 
the face of which the bank has written or stamped the words "accepted" or 
"certified", along with the signature of a bank official. A certified check is an 
obligation of the bank, not of the depositor. 

In order to generate a certified check, according to the present invention, a 
depositor writes a personal or business check. The depositor then enters the 
check value, check number, account number, customer ID and date into the 
remote user terminal, which generates a registration code. The registration code is 
then transmitted to the issuer central controller, either over a voice telephone 
channel via the issuer voice response unit (IVRU), or over a data channel via a 
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modem or a data network. As described above, the remote user terminal may 
automatically generate some of the required information. The central control 
determines whether the received customer ID is found in the membership 
database. If the received customer ID is found in membership database, the 

5 specified bank account is checked to ensure that sufficient funds are available to 
cover the check. If so, the amount of the check is debited to the account and 
credited to the check certifier. A verification code is then transmitted to the 
remote user terminal, either directly or through the IVRU and the user. The 
remote user terminal generates a completion code based on the verification code, 

10 transmits the completion code to the central controller, either directly or through 

O the IVRU and the user, and commands the printer to print a certified check having 

□ 

0 the certification information on the check. 

W\ ty/W Th^fe has thus been provided a new and improved method and system for 

SI * v / 

W providing user^nerated traveler's checks. The system, which uses components 

"Ml 5 available to the ordinar^£pnsumer, permits a user to generate verifiable traveler's 
Q checks, in any quantity and^ctejiomination selected by the user, without leaving 

p his home or place of business. The^stem is preferably implemented with user- 

friendly software, and necessary communications links for the process may be 
ordinary telephone. Further, such checks canSje verified by the cashing 
20 merchant, greatly diminishing the likelihood of fraud. 

Although a specific embodiment of the present invention has been 
described, it will be understood by those of skill in the art that there are other 
embodiments which are equivalent to the described embodiment. Accordingly, it 
is to be understood that the invention is not to be limited by the specific 
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illustrated embodiment, but only by the scope of the appended claims. 
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